Method and apparatus for ownership transfer of transactions in peer-to-peer systems

ABSTRACT

This invention relates to a method of, a device and a protocol for performing ownership transfer of a change in a peer to peer network ( 30 ). The device or a peer can be a car, a garage, a video cassette recorder (VCR), a personal digital assistant (PDA), a mobile phone, a climate system, a television, a lamp, a coffee machine, a radio, a DVD player, a CD player, an information panel, a web tablet, a smart remote, an answering machine, a personal computer. Said method includes the steps of attempting, by means of a first device ( 31 ) to find a second device ( 32 ) which will accept responsibility for committing said change; transferring, by means of said first device, responsibility of committing the change to said second device and propagating the change to said second device, wherein a global commit status variable is further transferred to said second device and where said global commit status variable is maintained on said second device; setting, by means of said first device, a local commit status variable to “provisional” signifying that the device will act as if the global commit went through, wherein said first device will wait with setting the local commit status variable to ‘void’, signifying a real commit, until it gets confirmation that the global commit status variable is set to ‘void’ also, when said first device re-enters said network and checks the status of the global commit status variable; or setting, by means of said first device, the local commit status variable to ‘void’ signifying a real commit; and propagating, by means of said second device, said change to one or more devices ( 33, 34 ) for which said change is relevant, when responsibility of committing the change is received and accepted on said second device.

This invention relates to a method of performing ownership transfer of achange in a peer to peer network.

The change is transferred among various devices in said peer to peernetwork.

The present invention also relates to a computer system for performingthe method.

The present invention further relates to a computer program product forperforming the method.

Additionally, the present invention relates to a protocol for ownershiptransfer of a change.

The present invention further relates to a device corresponding to apeer, which belongs to said peer to peer network.

The invention further relates to a computer program product comprisingcode means stored on a computer readable medium for performing such amethod.

WO 02/39305 discloses information management via delegated control. Aninformation management system utilizes delegated control over a dataset.Said information management system comprises more computers and moresoftware applications interacting to store information. Said delegatedcontrol is a transfer, temporary or partially of said dataset from adelegating system (as a so called “delegator”) to a delegate system.

Committing transactions or delegating control in distributed databasesis known to be difficult. In the art, currently there are three optionsfor a basic transaction model:

Firstly, the originating part sends the update to a central transactionserver and this server is responsible for updating all relevant partsand committing the change.

Secondly, the originating part propagates an update to all parts of thedatabase that are relevant and commits the change as soon as it gets amessage from all relevant parts that they received the update.

Thirdly, the commitment is not performed explicitly. There areprotocols, e.g. so called “gossip protocols” that just propagate thechange and assume a commit (see references below).

David Kempe, Jon M. Kleinberg, and Alan J. Demers. Spatial gossip andresource location protocols. In ACM Symposium on Theory of Computing,pages 163-172, 2001.

Alan Demers, Dan Greene, Carl Houser, Wes Irish, and John Larson.Epidemic algorithms for replicated database maintenance. SIGOPS,22(1):8-32, 1987.

The first option of using the server is a problem since not alldistributed database have a central server that controls alltransactions, e.g. in P2P (peer to peer) systems. In which case, thefirst option is out of question.

In addition, some distributed databases have parts that are not alwaysin contact with all relevant parts and/or the central transactionserver, i.e. ad-hoc connections, in which case the second option is outof question. As a result, the originating part may not be able committhe change.

In many cases it is not an option not to commit explicitly because itmeans that there is no certainty about the commit. In this case thethird option is out of question.

This leaves the problem of having no adequate reliable/robusttransaction model in a peer to peer communication, i.e. it is a problemthat a transaction of a change e.g. to a database, a file, etc.—wherethe database, the file, etc. resides on other peer(s) than that whowishes to have the change performed—in some occasions is not performed.As a consequence, said file, database, etc. is left un-updated—and whatis even worse—the requester of said change is not aware of it.

From the art it is known that Peer-to-peer is a communications model inwhich each party (i.e. each peer) has the same capabilities and eitherparty can initiate a communication session. Other models with which thePeer-to-peer communications model might be contrasted include theclient/server model and the master/slave model, both also known in theart. In some cases, peer-to-peer communications is implemented by givingeach communication node both server and client capabilities. In recentusage, peer-to-peer has come to describe applications in which users canuse the Internet to exchange files, update databases with each otherdirectly or through a mediating server.

On the Internet, peer-to-peer (referred to as P2P) is a type oftransient Internet network that allows a group of computer users (peers)with the same networking program to connect with each other and directlyaccess files from one another's hard drives. Napster and Gnutella areexamples of this kind of peer-to-peer software. Corporations are lookingat the advantages of using P2P as a way for employees to share files,update and access common databases, information, etc without the expenseinvolved in maintaining a centralized server and as a way for businessesto exchange information with each other directly.

When the Internet P2P is applied, it is known in the art that the usermust first download and execute a peer-to-peer networking program, e.g.Gnutella-net is currently one of the most popular of these decentralizedP2P programs because it allows users to exchange all types of files.After launching the program, the user enters the IP address of anothercomputer belonging to the network, typically, the Web page where theuser obtained the download will list several IP addresses as places tobegin. Once the computer finds another network member on-line, it willconnect to that user's connection, which has obtained their IP addressfrom a connection of another user, and so on.

It is further known in the art that users of peers can choose how manymember connections to seek at one time and determine which files,databases, information items, etc they wish to share, update or passwordprotect, but still said problems are left unsolved.

However, said problems are solved by said method of the presentinvention, when the method comprises the steps as discussed in FIG. 4.

It is hereby an advantage of the invention that a method and a protocol,respectively is proposed that enables the delegation of theresponsibility to commit a change.

The invention further has the advantage that commitment of a change canbe effectuated even if the initiator (first device as claimed) of thechange is no longer connected.

In most cases the integrity of the distributed database can bemaintained and guaranteed. Further, by not having a central server makespeer to peer network less vulnerable and further enables for any highnumber of peers communicating, i.e. the network can be scaled up anddown and still has said advantages.

Said system, protocol and device, respectively provides the sameadvantages and solves the same problem(s) for the same reasons asdescribed previously in relation to the method.

The invention will be explained more fully below in connection withpreferred embodiments and with reference to the drawings, in which:

FIG. 1 shows various ways for a peer in contact with the systemtransferring responsibility for an update to a peer in constant contactwith the system;

FIG. 2 shows responsibility transfer with status change on a commitstatus variable;

FIG. 3 shows a network of devices;

FIG. 4 shows a method of performing ownership transfer of a change in apeer to peer network, and

FIG. 5 shows commit status variable changes during transaction ownershiptransfer.

Throughout the description of the present invention, transaction isunderstood as the following:

In computer programming, a transaction usually means a sequence ofinformation exchange and related work (such as a database or a fileupdating) that is treated as a unit for the purposes of satisfying arequest and for ensuring database or file integrity. For a transactionto be completed, and database or file changes to be made permanent, thetransaction has to be completed in its entirety. A typical businesstransaction could be a catalogue merchandise order phoned in by acustomer and entered into a computer by a customer representative. Theorder transaction involves checking an inventory database, confirmingthat the item is available, placing the order, and confirming that theorder has been placed and the expected time of shipment. If this isconsidered as a single transaction, then all of the steps must becompleted before the transaction is successful and the database isactually changed to reflect the new order. If something happens beforethe transaction is successfully completed, any changes to the databasemust be kept track of so that they can be undone, e.g. rolled back.

FIG. 1 shows various ways for a peer in contact with the systemtransferring responsibility for an update to a peer in constant contactwith the system.

In the figure, reference numeral (a) shows a peer in temporary contactwith the system transferring responsibility (square) for an update (darkdot) to a peer in constant contact with the system.

Reference numeral (b) shows how the second peer accepts and theoriginator does a provisional commit (white dot).

Reference numeral (c) shows that the acceptor propagates the change tothe other relevant peers.

Reference numeral (d) shows how the other peers acknowledge the changeand that the change is committed (grey dots).

Reference numeral (e) shows that if the originator comes into contactwith the system again it will check the status of the change.

Reference numeral (f) shows that the acceptor acknowledges the commit inthe system.

FIG. 2 shows responsibility transfer with status change on a commitstatus variable.

This figure illustrates three deviations from FIG. 1:

-   1) The original acceptor propagates the responsibility to other    peers (a reason could be 3)).-   2) The originator assumes a real commit instead of a provisional.-   3) The scope of the peers is more limited.

Reference numeral (a) shows a peer in temporary contact with the systemtransferring responsibility (square) for an update (dark dot) to a peerin constant contact with the system. Reference numeral (b) shows thatthe second peer accepts and that the originator assumes it can do a realcommit (grey dot). Reference numeral (c) shows that the acceptorpropagates the change (dark dot) and that the responsibility (square) toother relevant peers it is in contact with. Reference numeral (d) showsthat both accepting peers accept responsibility and that the originalacceptor does a real commit. Reference numeral (e) shows that thedelegated acceptors propagate the update to further peers. Referencenumeral (f) shows that the final update receiving peers acknowledge thecommit in their system and that the delegated acceptors do the same. Thelatter also dissolves the update task.

With respect to state transition, three types of commits are mentioned,these are correspondingly reflected in a commit status variable havingvarious states, i.e. a real commit state, a provisional commit state oran assumed commit state, however the assumed commit is not a separatestate, i.e. it is the same state as a real commit, but reached through adifferent transition.

The assumed commit state is a real commit without confirmation. Theinitial state is uncommitted. The final state is committed. This isidentical to the real commit state. The difference is that the realcommit gets confirmation in-between. Note that the assumed commit statecan dangerous, since it can lead to inconsistencies, i.e. if the updateis not committed by other peers, even though the update was assumed tooccur. For this reason the state of a provisional commit can be applied.So the difference between the assumed commit state and the provisionalcommit state is that in the latter case there is still a flag (or asimilar indication) that indicates that the commit (state provisional)was not confirmed. If the confirmation arrives later, this flag can beremoved, i.e. the commit state changes into (really) committed, i.e. thestate of a real commit. So the state of a provisional commit can be seenas a ‘real’ commit for which the confirmation is expected to be late.

So, regarding commitment, four states exist for the commit statusvariable. By only looking at commitment there is no difference between 0and 3, i.e. the database is with 3 in an updated state, but no updatesare pending:

-   (0) no update pending=no state regarding commitment;-   (1) uncommitted=update pending;-   (2) provisional commit=update is committed to the database but    unconfirmed; and-   (3) real commit=update is confirmed (others commit) or assumed and    committed.

In state (0) an update request is received, which brings it to state(1). The peer can now wait till it gets a confirmation (realcommit=state (3)), assume confirmation (assumed commit=state (3)), orpretend for the moment that it has the confirmation, because it expectsit will get it later (provisional commit=state (2)).

State (2) becomes state (3) if (finally) confirmation arrives. State (3)equals state (0), i.e. the updated state which corresponds to that noupdate is pending.

FIG. 3 shows a network of devices. Said network of devices isillustrated by means of reference numeral 30. As will be explained moredetailed in the next figure, a first device, reference numeral 31, willdo the attempt to find another, i.e. a second device, reference numeral32, which will accept responsibility for committing a change. As aresult, said second device will propagate the change to at least onemore device, e.g. reference numerals 33 and 34 assuming said change isrelevant for these devices. In the network further devices may bepresent, e.g. reference numerals 35, 36 and 37. The network is shown forillustrative purposes, any other dynamic or static topology orarrangement of peers or devices may also be applied in the presentinvention.

Any of said devices may be a car, a garage, a video cassette recorder(VCR), a personal digital assistant (PDA), a mobile phone, a climatesystem, a television, a lamp, a coffee machine, a radio, a DVD player, aCD player, an information panel, a web tablet, a smart remote, ananswering machine or a personal computer. As an example, in principle,the lamp with access to the network may communicate change, e.g. aschedule change to a personal digital assistant (PDA), a web tablet, asmart remote, an answering machine and/or a personal computer, hereby itis assured that the user most likely will receive said schedule change.

The device alternatives as mentioned may be understood as correspondingpeers in a peer-to-peer type of transient network similar to the typefound on the Internet, that allows a group of computer users (withaccess to their corresponding peers or devices) with the same or similarnetworking program or protocol to connect with each other and directlyaccess and/or update files, databases, etc to/from one another's harddrives, memories, etc. A peer-to-peer network is simply a network ofpeers, the Internet, Gnutella software, computers are all just examplesof aspects of specific implementations.

Said state change can be applied in a protocol used for ownershiptransfer of a change, i.e. the protocol will comprise a commit statusvariable having various states, i.e. a real commit, and a provisionalcommit. If the originator of an update request tries to transfer theresponsibility for commitment, it can also communicate which state itwill be in after the responsibility is accepted by another. Theoriginator can be uncommitted, committed or provisionally committed. Thefirst case, i.e. the originator is uncommitted, is avoided according tothe present invention since the acceptor needs to wait for commitmentfrom the originator. The second case, i.e. the originator is committed,committed requires no further action from the acceptor towards theoriginator. The third case, i.e. the originator is provisionallycommitted, means that the acceptor needs to keep in mind that theoriginator may want or need confirmation later.

Note that any type of commit is a state change, i.e. the assumed commitis not a state it is a state transition.

The protocol may be applied in ownership transfer of changes amongvarious devices (similar to peers), e.g. in a peer to peer network or ina similar network without a central server, it can in fact also beapplied in a system with a central server but it makes less sense.

Said change can be any change to a database and/or to a file.Additionally or alternatively, said change may be a change to anyinformation item, such as a variable, one or more parameters, one ormore status flags, a string variable, etc.

In other words, said change may have the effect that text, numericalinformation, picture, video, sound and combinations thereof subsequentlyare updated in a file and/or a database.

The file and/or database may be stored individually or distributed inany device communicating on the peer to peer network or in a similarnetwork.

In the following various practical applications of the invention areshown, the update is similar to said change.

EXAMPLE 1 Travelling Commits

Johan has forgotten certain drawings in his vault at home. He has notime to get them and asks Hendrik to get them for him. He changes hissecurity settings of his home on his PDA device to allow Hendrik intohis garage, his study and to open his vault. However, for securityreasons he can not change these settings online. He transfers theresponsibility for the update of his settings to his car and givesHendrik his car keys. Hendrik uses the car of Johan to drive to Johan'shome. As Hendrik reaches Johan's home, the car—as another device in thenetwork—transfers the update of the security settings to the garage. Thegarage propagates the change to the rest of the devices of the home andHendrik can get what he came for. As Hendrik leaves, security settings,i.e. a new change, are reverted to exclude Hendrik again. The garage—asyet another device in the network—informs the car of this update, i.e.the change. Back with Johan in the office the car updates the settingson Johan's PDA and Johan can trust that all is back to normal again.Hendrik hands him the drawings.

EXAMPLE 2 Fire and Forget Approach to Updating Code or Parameters onMany Peers or Devices

Pieter invites Fien to visit him for dinner. Unexpectedly, she says yes.He uses his mobile phone—as yet another device in the network—to preparehis ambient home for dinner with Fien. He has no time to go through allchanges required but his answering machine (as another device, etc)accepts responsibility for propagating this information to all otherrelevant devices. As his PVR (as another device, etc) gets thisinformation it prepares to record the live cricket game Pieter intendedto watch. The climate system (as another device, etc) prepares toelevate the temperature from the usual 18 degrees to 19.5 degreescentigrade. The kitchen checks its stocks for a dinner for two with someclass. It decides to order in some Cajun food. The messaging servicereschedules the appointment with the 24 hours dentist on hiscorresponding device, e.g. his PDA. As Pieter gets home, he immediatelygets informed that all but one of the changes due to dinner with Fienwere successful so he can relax in anticipation of the arrival of Fien.There is one hitch, the rescheduling of his dentist appointment did notsucceed and he will have to make a new appointment himself. The Cajunfood arrives 15 minutes before Fien does so Pieter has time to put it inhis own cooking ware.

OTHER EXAMPLE

-   -   A group of persistent peers sort of emulate a central server        towards multiple ad-hoc connected devices. At home Wubbo has        several persistent peers that together handle his agenda Any        device can always offload an item for the agenda to any of the        persistent peers (i.e. devices) and rely on the change being        committed.    -   Fast offload of updates before a pending shutdown. Carol's smart        remote (as another device, etc) could not commit all pending        changes before an imminent shutdown due to loss of power. It        transfers responsibility to one of the responders (as other        devices, etc) in the wall.    -   A task may require a sequence of devices each performing a        subtask. The responsibility for the task travels with the task.

FIG. 4 shows a method of performing ownership transfer of a change in apeer to peer network. Said peer to peer network is similar to thenetwork of devices from the foregoing figure, i.e. the ownershiptransfer of the change can be performed among devices in said networks.

Prior to the following steps, it is assumed that a change is originatedat a device. This can be seen in the next figure, FIG. 5 which isgenerally also referred to in the present method description. In FIG.5(a), the originator or the first device as claimed (corresponding toreference numeral 31 in FIG. 3)) attempts to find another, i.e. a seconddevice, reference numeral 32, etc. At this stage only the first deviceknows about the change because it has not been communicated to any otherdevices. Two commit status variables are instantiated, which (to beginwith) are both maintained by this originator. The first commit statusvariable has a local scope, signifying the status of the local database(value at this stage: ‘pending’). The second commit status variable hasa global scope, signifying whether the change has been committed in allrelevant peers (value at this stage: ‘pending’).

The second device was previously called the acceptor since it may acceptresponsibility for committing said change.

In step 100 (FIG. 1 a, FIG. 2 a, FIG. 5(b), the first device may attemptto find a second device which will accept responsibility for committingsaid change.

The attempt may prove not to be a success, i.e. all commit states(commit status variables) remain ‘pending’ and the first device willhave to try again (to find another device to accept responsibility forcommitting said change) or it may prove to be a success, i.e. the nextstep.

In step 200 (FIG. 1 b, FIG. 2 b, FIG. 5(c), said first device may thentransfer responsibility of committing the change to said second device.This means propagating the change to the acceptor (second device).Furthermore, this means that the responsibility for maintaining theglobal commit status variable is transferred to the second device. Thelocation of this global variable will be on the second device.

In step 300, the originator, i.e. said first device, may set its localcommit status variable to ‘provisional (FIG. 1 b, FIG. 2 b, FIG. 5(d2)), which signifies the device will act as if the global commit wentthrough, but it will wait with setting the local commit status variableto ‘void’ until it gets confirmation that the global commit statusvariable is set to ‘void’ also. E.g. when said first device re-enterssaid network and check the status of the global commit status variable.

Normal procedure is to first check whether all parts of a databaseaccept a certain change and then committing it (i.e. really goingthrough with it). If a database is distributed, a device has topropagate the change to all relevant parts and they have to say thatthey accept the change. They do the latter by sending a message to thateffect to the part of the database that is responsible for committingthe change (is maintaining the global commit status variable). In a P2Psetting this is normally the originator (1^(st) device), according tothe present invention it is the acceptor (2^(nd) device). If theacceptor has confirmation from all peers (devices) that should apply thechange that they will actually apply the change then the acceptor knowsthat the change is globally committed, so the global commit variable canbe set to void.

The local commit status variable indicates whether the local databasehas applied the change or not.

The global commit status variable indicates whether all peers haveapplied the change or not.

Alternatively, in step 310, the local commits status variable may be setto ‘void’ which signifies a real commit (FIG. 2 b, FIG. 5(d 1)).

Said first device can wait or have to wait a certain amount of timebefore re-entering the network, and hereby—in the unconnectedsituation—resources may be freed to other tasks than communicating withthe network, i.e. when said first device is a Personal Video Recorder itcan dedicate its resources to record a movie.

In step 400, said second device may propagate said change to one or moredevices for which said change is relevant (FIG. 1 c, FIG. 2 c, FIG. 5(e, f, g, h)). This is the case when responsibility of committing thechange is received and accepted on said second device.

The method may here be successfully finished, i.e. the ownershiptransfer of the change is here successfully transferred.

However, it is possible that said method may further comprise thefollowing two steps.

In step 500, said first device may convert the local commit statusvariable of a provisional commit into a real commit. This is the casewhen said first device re-enters said network and receives a messageindicating a successful commit from said second device (FIG. 5 (i)).

Again, said first device may wait a certain amount of time beforeentering the network. It may have the experience—from former situationsspend unconnected—that it will take some time before the second deviceeventually will provide said successful commit message.

The originating device (said first device) may also convert theprovisional status to ‘void’ after not being connected for apredetermined amount of time.

In step 600, said first device may receive a message indicating a nonsuccessful commit from said second device. That is the case whencommitting the change globally is not successfully performed by saidsecond device, e.g. because the second device failed to reach allrelevant peers or because one or more peers refused to commit the change(e.g. due to locking or conflicting updates). Said message may bereceived when said first device enters said network the next time.

The method may here be successfully finalized; however it is possiblethat said method additionally comprises the following step.

The values of the variables and the names of the parameters can bechanged without departing from the concept of the invention. For examplethe value of the parameter “global commit status” can be “commit” instead of “void” to indicate that the commit was a success.

In step 700, said first device may roll back said change. This is thecase, for instance, when the local commit status (variable) is theprovisional commit and step 600 occurs. The other peers (devices) didnot commit so the provisional commit on the originator (first device)needs to be rolled back. If step 600 occurs and the originator hasperformed previously a real commit then no local commit status variableexists anymore for the change in question and the database isinconsistent. To remedy the situation the originator may initiate thesame change again (i.e. retry) or initiate a new change to counter thefirst change and to lift the inconsistency.

A computer readable medium may be magnetic tape, optical disc, digitalversatile disk (DVD), compact disc (CD record-able or CD write-able),mini-disc, hard disk, floppy disk, smart card, PCMCIA card, etc.

In the claims, any reference signs placed between parentheses shall notbe constructed as limiting the claim. The word “comprising” does notexclude the presence of elements or steps other than those listed in aclaim. The word “a” or “an” preceding an element does not exclude thepresence of a plurality of such elements.

The invention can be implemented by means of hardware comprising severaldistinct elements, and by means of a suitably programmed computer. Inthe device claim enumerating several means, several of these means canbe embodied by one and the same item of hardware. The mere fact thatcertain measures are recited in mutually different dependent claims doesnot indicate that a combination of these measures cannot be used toadvantage.

1. A method of performing ownership transfer of a change in a peer topeer network (30), said method comprising the steps of: attempting(100), by means of a first device (31) to find a second device (32)which will accept responsibility for committing said change;transferring (200), by means of said first device, responsibility ofcommitting the change to said second device and propagating the changeto said second device, wherein a global commit status variable isfurther transferred to said second device and where said global commitstatus variable is maintained on said second device; setting (300), bymeans of said first device, a local commit status variable to“provisional” signifying that the device will act as if the globalcommit went through, wherein said first device will wait with settingthe local commit status variable to ‘void’, signifying a real commit,until it gets confirmation that the global commit status variable is setto ‘void’ also, when said first device re-enters said network and checksthe status of the global commit status variable; or setting (310), bymeans of said first device, the local commit status variable to ‘void’signifying a real commit; and propagating (400), by means of said seconddevice, said change to one or more devices (33, 34) for which saidchange is relevant, when responsibility of committing the change isreceived and accepted on said second device.
 2. A method according toclaim 1 further comprising the steps of: converting (500), by means ofsaid first device, the local commit status variable of a provisionalcommit into a real commit, when said first device re-enters said networkand receives a message indicating a successful commit from said seconddevice; and receiving (600), a message on said first device indicating anon successful commit from said second device if committing the changeis not successfully performed by said second device, when said firstdevice re-enters said network.
 3. A method according to claim 2 furthercomprising the step of: rolling back (700), by means of said firstdevice, said change when the local commit status variable is theprovisional commit and the situation of the receiving step (600) occurs.4. A method according to claim 1 characterized in that said change is atleast one of a change to a database, a change to a file and a change toan information item.
 5. A method according to claim 1 characterized inthat any of said devices is one of a car, a garage, video cassetterecorder (VCR), a personal digital assistant (PDA), a mobile phone, aclimate system, a television, a lamp, a coffee machine, a radio, a DVDplayer, a CD player, an information panel, a web tablet, a smart remote,an answering machine, a personal computer, or any other electronicdevice.
 6. A protocol for ownership transfer of a change characterizedin that the protocol comprises a commit status variable having at leastone of the states of a real commit and a provisional commit.
 7. A device(31) for performing ownership transfer of a change, said device (31)comprising: means for attempting to find a second device (32) which willaccept responsibility for committing said change; means for transferringresponsibility of committing the change to said second device (32) andpropagating the change to said second device (32), and means fortransferring a global commit status variable to said second device (32);means for setting a local commit status variable to “provisional”signifying that the device (31) will act as if the global commit wentthrough, when said device (31) waits with setting the local commitstatus variable to ‘void’, signifying a real commit, until it getsconfirmation that the global commit status variable is set to ‘void’also, when said device (31) re-enters said network and checks the statusof the global commit status variable; or means for setting the localcommit status variable to ‘void’ signifying a real commit; and means forpropagating said change to one or more devices (33, 34).
 8. A device(31) according to claim 7, said device (31) further comprising: meansfor converting the local commit status variable of an provisional commitinto a real commit; and means for receiving a message indicating a nonsuccessful commit.
 9. A device (31) according to claim 8, said device(31) further comprising: means for rolling back said change.
 10. Acomputer system for performing the method according to claim
 1. 11. Acomputer program product comprising program code means stored on acomputer readable medium for performing the method of claim 1 when thecomputer program is run on a computer.